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REMARKS/ARGUMENTS 

Claims 1 - 30 are pending. None of the claims have been amended. No claims 

have been canceled. No claims have been added. 

Claims 1 - 30 were rejected under 35 U.S.C. § 102(e) for allegedly being 
anticipated by Brodersen et al. 5 U.S. Patent No. 6,266,669. It appears the cited reference is not 
listed on form PTO-892 accompanying the instant Office action. Furthermore, it appears that the 
cited reference has not been cited in an IDS. While counsel for Applicants has obtained a copy 
of the reference in order to respond to the instant Office action, the Examiner is respectfully 
requested to place a form PTO-892 listing U.S. Patent No. 6,266,669 into the record. 

The invention as recited in the pending claims, as originally filed, is directed to 
processing a database query request. Aspects of the invention, as recited in claim 1 for example, 
include "obtaining a first data item from a database table ... in response to a query request." A 
"second data item [is obtained] based on a value related to said first data item, said value in an 
updated log file of said database system." A final result to the query request is then produced by 
"integrating said first and second data items into an integration result." 

Brodersen et al. disclose "a method of maintaining a partially replicated database 
in such a way that updates made to a central database, or to another partially replicated database, 
are selectively propagated to the partially replicated database." Col. 2, lines 34 - 38. Fig. 3 of 
Brodersen et al. shows the steps for updating a database; e.g., deleting a row, adding a row, or 
changing a value in a cell. Col. 8, line 60 - col. 9, line 2. 

An aspect of the invention recited in claim 1 is obtaining a "second data item 
based on a value related to said first data item, said value in an updated log file of said database 
system." Brodersen et al. show in Fig. 3 a step of creating a log record, 107. In step 107, "the 
update manager 3 1 creates a log record describing the update and writes it to update log 35." 
Col. 9, lines 4-5. Step 107 does not describe obtaining a "second data item." Step 107 merely 
describes writing information to a log file. 

Brodersen et al. was cited at col. 15, lines 1-11. The cited text describes a 
"Visibility Calculator, in conjunction with the Log Manager is therefore able to determine what 
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subset of update transaction data is required to be routed to any particular node." Brodersen et 
al. appear to describe how an update operation is propagated. Respectfully, this cited text does 
not describe obtaining a "second data item" or that the second data item is based on a "value 
related to said first data item" that is contained in "an updated log file." 

Still another aspect of the invention recited in claim 1 is "integrating said first and 
second data items into an integration result." Brodersen et al. was cited at col. 9, line 36 - col. 
10, line 62 for allegedly showing this aspect of the invention. The cited text discusses "docking 
processing" and "merge processing." Docking processing is a procedure "whereby the user 
requests that the node dock with central computer 1 to upload an update log such as update log 
35-a to central computer 1." Col. 9, lines 40 - 42. Docking processing does not teach 
"integrating ... a first data item" obtained from a query request with a "second data item" 
obtained from an update log. Docking processing, as understood, simply refers to uploading a 
log file from a central computer. 

Merge processing "serves to update its associated database with a transaction that 
has been entered by a user of a computer remote from the computer where merge processing is 
being performed." Col. 10, lines 12-13. As understood, this process simply updates a local 
database with updates that occur at a central database. Performing a database update does not 
involve obtaining data from a query request. Merge processing is the process of updating a 
database. Since there is no data that is obtained from a query request, there can be no integrating 
of such data. Therefore, merge processing does not teach "integrating ... a first data item" 
obtained from a query request with a "second data item" obtained from an update log. 

Claims depending from claim 1 are not anticipated by Brodersen et al. for the 
same reason or reasons that claim 1 is not anticipated by Brodersen et al. The apparatus and 
software claims corresponding to claim 1 are not anticipated by Brodersen et al. for the same 
reason or reasons that claim 1 is not anticipated by Brodersen et al. Claims 20 - 30 were rejected 
based on the reasons set forth in the rejection of the earlier claims. Therefore, claims 20 - 30 are 
not anticipated by Brodersen et al. for the same reason or reasons that claim 1 is not anticipated 
by Brodersen et al. 
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It is earnestly submitted that for any one of the foregoing reasons, the Section 102 



rejections of the claims are believed to be overcome. 



In view of the foregoing, Applicants believe all claims now pending in this 



Application are in condition for allowance. The issuance of a formal Notice of Allowance at an 
early date is respectfully requested. 



If the Examiner believes a telephone conference would expedite prosecution of 



this application, please telephone the undersigned at 650-326-2400. 



TOWNSEND and TOWNSEND and CREW LLP 

Two Embarcadero Center, 8 th Floor 

San Francisco, California 941 1 1-3834 

Tel: 650-326-2400 

Fax: 415-576-0300 

GBFYxmm 
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CONCLUSION 




George B. F. Yee 
Reg. No. 37,478 
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